home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ 6⁄1⁄90 / 1366-Potential Failure Pr-May90 < prev    next >
Encoding:
Text File  |  1990-06-01  |  1.3 KB  |  39 lines  |  [TEXT/GEOL]
  1. Item    9770627                         29-May-90        17:19PDT
  2.  
  3. From:   CDA0004                         VAR Shana Corp, Don Murphy,IVR
  4.  
  5. To:     MACAPP.TECH$                    MacApp Technical
  6.  
  7. Sub:    Potential Failure Problem
  8.  
  9. Attn: MacApp.Tech$
  10. SentBy: Wayne Malkin
  11. Date   5/29/90
  12. Subject    Potential Failure Problem
  13. From   Wayne Malkin
  14. To MacApp.Tech$
  15.  
  16.  Memo         Subject:Potential Failure Problem
  17.  
  18. For anyone out there like me who tends to ignore the good advice of the people
  19. that designed and wrote MacApp, here is something to watch for:
  20.  
  21. If you go ahead and CatchFailures with a global failure handler (even though
  22. Larry Rosenstein said it wasn't designed for that), make sure the failure
  23. handler is in a different segment from the CatchFailures call (or in a
  24. resident segment).
  25.  
  26. If you aren't careful, you could find your failure handler getting moved when
  27. its segment gets unloaded. Since CatchFailures saves the address of the
  28. failure handler procedure, this is a BAD THING. Putting the failure handler in
  29. a different segment fixes it, since the CatchFailures call will pass the jump
  30. table address. Putting it in a resident segment is ok, since then it won't
  31. move on you. There is also a compiler flag {$B+} you can use to force
  32. CatchFailures to use the jump table address, even if the failure handler is in
  33. the same segment.
  34.  
  35. -- Wayne Malkin
  36.  
  37.  
  38.  
  39.